Skip to content

Refactor (packages/opencode/src/util/repository.ts): Function with many returns - #39

Open
Yasa-Khan wants to merge 2 commits into
CMU-17313Q:mainfrom
Yasa-Khan:refactor/repository-many-returns
Open

Refactor (packages/opencode/src/util/repository.ts): Function with many returns#39
Yasa-Khan wants to merge 2 commits into
CMU-17313Q:mainfrom
Yasa-Khan:refactor/repository-many-returns

Conversation

@Yasa-Khan

@Yasa-Khan Yasa-Khan commented Sep 2, 2026

Copy link
Copy Markdown

P1B: Starter Task: Refactoring PR

1. Issue

Link to the associated GitHub issue:
#38

Full path to the refactored file:
packages/opencode/src/util/repository.ts

What do you think this file does?
This file parses repository references (GitHub shorthand, SCP-style git URLs, host/path URLs, and local file paths) into a normalized Reference object, and provides helpers to validate branch names, compare references for cache identity, and compute local cache paths for cloned repositories.

What is the scope of your refactoring within that file?
I refactored the parseRepositoryReference function, extracting its four parsing strategies into separate helper functions: tryGithubPrefixedReference, tryScpReference, tryDirectReference, tryShorthandReference, and tryUrlReference.

Which Qlty-reported issue did you address?
"Function with many returns" , parseRepositoryReference had a return count of 8 before the change.

2. Refactoring

How did the specific issue you chose impact the codebase's maintainability?
With 8 return statements spread across nested conditionals, it was hard to tell at a glance which parsing strategy applied to a given input, making the function difficult to modify safely or extend with new reference formats without risking regressions in unrelated branches.

What changes did you make to resolve the issue?
I extracted each parsing strategy into its own named function that returns undefined when its pattern doesn't match (signaling "try the next strategy") or a Reference | null when it does match, reducing parseRepositoryReference itself to 4 return statements that simply chain through the strategies in order.

How do your changes improve maintainability? Did you consider alternatives?
Each strategy is now independently readable, testable, and named after what it does, so future changes to one format (e.g. adding a new host pattern) don't require re-reading the entire original function. I considered converting the nested ifs into a single lookup table, but kept the sequential-strategy approach since it preserves the exact original fallthrough order and is more explicit about precedence (e.g. github: prefix always checked before generic shorthand).

3. Validation

How did you validate that the change is correct?
I ran the existing 6-test suite in test/util/repository.test.ts against the refactored code and confirmed all tests still pass; I also added 3 new tests to cover branches that were previously untested (the github:owner/repo prefix shorthand, parseGitHubRemote, and the custom GitHub base URL override), bringing the total to 9 passing tests, and confirmed via bun test --coverage that all new helper functions are exercised.

Attach a screenshot of the test coverage showing the lines were executed by the tests.
Screenshot 2026-09-02 at 6 34 14 pm

Attach a screenshot showing the tests that cover the change passing during CI
Screenshot 2026-09-02 at 8 24 09 pm

Attach a screenshot of qlty smells --no-snippets <full/path/to/file.ts> showing fewer reported issues after the changes.
Screenshot 2026-09-02 at 6 59 46 pm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant